Бизнес требования при разработке IT проектов
Текст | Андрей Соловьев, создатель компании “Smart Software Design”
Если по каким-то причинам ваша компания решила создавать программный продукт, но не обладает компетенциями в области его разработки, то, скорее всего, вы озаботитесь поиском исполнителя-разработчика. Важно правильно сформулировать бизнес-требования. Это документ, в котором будет отражено, что именно вы хотите получить в качестве результата, и который будет являться основой для определения целевого time-to-market для вашего проекта, тендерной процедуры, управления проектом, а также определит юридические особенности отношений с исполнителями.
Создатель компании “Smart Software Design” Андрей Соловьев – эксперт в проектировании программного обеспечения, успешный IT-предприниматель, выпускник бизнес школы университета Чикаго (Chicago Booth) – расскажет, как правильно поставить задачу для исполнителей-разработчиков, как наладить здоровую коммуникацию, чтобы не потратить лишних денег и получить нужный продукт.
— Наша компания “Smart Software Design” занимается проектированием программного обеспечения. По сути – выполняет функции архитектора и технического заказчика в проектах создания софта. Мы делаем только архитектуры, требования, организуем тендерные процедуры, ведем управление проектами и осуществляем контроль качества. При этом мы не осуществляем непосредственно разработку — так мы избегаем конфликта интересов между разработчиками и проектировщиками.
Структура того, что хотим
Любой софтверный продукт имеет приоритеты реализации своего функционала. Приоритеты вырабатываются по разному.
При выводе софтверного продукта на рынок конкурентная стратегия фиксирует, как это нужно сделать. А именно:
— определение того, какие элементы продукта будут представлены пользователям изначально для тестирования рынка и спроса;
— ожидаемые конкурентные ответы;
— характеристики последующих элементов продукта, которые будут выводиться на рынок как ответ на конкурентные действия;
— идеи относительно развития этого продукта, находящиеся за пределами текущего горизонта планирования…
Если софтверный продукт будет использоваться внутри организации, то этапность создания такого ПО:
- очередность введения функционала, исходя из потребностей пользователей внутри компании;
- сбор обратной связи;
- корректировка набора функциональностей;
- введение функционала второй и последующего очередей.
Необходимость модульного подхода со стороны бизнеса к будущему функционалу софта определяет, как следует думать о бизнес-требованиях. Нужно уметь разрабатывать продукт блоками, иметь возможность в произвольном порядке менять очередность разработки таких блоков. Обычно таким набором блоков выступает Customer Journey Map – карта пользовательских сценариев.
Важно, что каждый сценарий должен создавать ценность для пользователя. Например, функционал регистрации пользователя – это не отдельный пользовательский сценарий. Сложно представить себе сервис, в котором пользователи будут платить деньги просто за регистрацию на каком-то ресурсе. Они могут регистрироваться, только если приходят получать какую-то услугу. Этот пример помогает понять, что значит создание ценности для пользователя.
Наша компания проектировала разные системы, в которых было разное число пользовательских сценариев: ~10 внутренняя MIS, ~30 b2c марктеплейс одной услуги, ~70 b2b маркетплейс. Важно держать в голове, что каждый пользовательский сценарий потенциально имеет право на жизнь как отдельно стоящий сервис, за пользование которым люди были готовы платить деньги.
Agile, не Agile?
Вопрос определения методологии разработки – это зачастую вопрос веры, а также субъективного, жизненного и профессионального опыта тех, кто его обсуждает. Однако следует принять во внимание: проекты разработки программного обеспечения базируются на требованиях, сформулированными людьми, и отражают взаимодействие между различными группами людей. Они включают, в том числе, рыночные оценки, субъективные оценки пользовательских предпочтений и прочие, довольно изменчивые сущности. Например, в сравнении с геологическими проектами, где внешние условия – а именно, геология, — не меняются тысячелетиями, внешние условия проектов разработки программного обеспечения пластичны, и они могут меняться достаточно быстро. Логично предположить, что система управления требованиями должна уметь обрабатывать такую пластичность. Agile, как система гибкой разработки, как раз эффективно решает эту задачу.
В то же время, нередко заказчиком становится компания или корпорация, где есть своя логика принятия решений, например, изменение карты пользовательских сценариев. Добавление или удаление отдельного сценария может потребовать некоторого взаимодействия подразделений в коллективе заказчика – маркетологов и финансистов, например. Что приводит к необходимости соблюдать регламенты заказчика.
Можно попробовать использовать Waterfall как альтернативу гибкому подходу. Это система разработки ПО, в которой требования определяются и жёстко фиксируются до момента начала разработки. Предполагается, что такие требования не должны изменяться в процессе разработки. В качестве характеристики реалистичности такого подхода можно вспомнить шутку, что в таких проектах “водопад может течь не только вниз, но и вбок, а иногда и вверх». И в этом есть своя логика, ведь требования, включающие реальные мнения (оценки рынка, пользовательские предпочтения), пластичны по определению.
Для корпоративного заказчика, который, с одной стороны, хотел бы гибко управлять требованиями, а с другой – иметь привычный механизм контроля изменений (принятия управленческих решений через согласование), оптимальным фреймворком работы можно считать модификацию Agile, известную уже около 20 лет – Agile Feature Driven Development (Agile FDD).
Эта модификация предлагает симбиоз фиксации требований и гибкости в их реализации. Требования фиксируются, скорее, на уровне набора концепций позволяющих определить бюджет, а именно – карты пользовательских сценариев. При этом остается высокий уровень гибкости в реализации этих сценариев. Соответственно заказчик может применять все свои процессы, связанные с определением контура продукта — менять пользовательские сценарии в составе карты пользовательских сценариев согласно принятым процедурам, вовлекать необходимые службы и подразделения, согласовывать возможные изменения бюджетных ограничений реализации такого продукта, применять прочие управленческие и организационные механизмы. В то же время отсутствие фиксации требований реализации отдельных сценариев, “вынос” этих решений на уровень оперативного взаимодействия сотрудников заказчика и исполнителя, решает задачу адаптивности процесса управления проектом.
Модульность
Блочность Agile достигается за счет снижения относительного объема обособленных требований. Обособленное требование – пользовательская история. Пользовательская история “Уведомление пользователя”. Реализовали этот функционал – научились уведомлять пользователей любых категорий, любыми методами уведомлений, просто по необходимости подключая новые.
Идея поручить написание пользовательских историй разработчику приводит к тому, что разработчик постарается максимизировать часы разработки, которые придётся оплатить заказчику. Кроме того, необходимо обладать предметным знанием, чтобы писать требования. Например, наша компания специализируется среди прочего на финансах и мы написали несколько тысяч пользовательских историй по этой теме.
Любой пользовательский сценарий состоит из набора пользовательских историй. Одна история может входить в несколько сценариев. Это обеспечивает контроль переиспользования кодовой базы для заказчика, и это — отдельный инструмент экономии бюджета заказчика.
Очередность создания пользовательских историй не очень важна, в нашей практике были случаи, когда заказчик фазировал разработку – в том числе и в рамках одного пользовательского сценария, и часть историй готовили для начала периода разработки, другую часть — ближе к его окончанию. Нет необходимости иметь все истории написанными при входе в разработку – часть можно “подвезти” по ходу проекта, что позволяет снизить время time-to-market , выполняя создание требований и собственно разработку в одно время.
Еще одна опция снижения time-to-market – параллелизация работы нескольких команд разработчиков. Сложность проектов создания ПО в том, что просто нагнать 50 человек инженеров – это не очень эффективно. Предельный размер команды, при котором известно, что делает каждый, – около 10 человек, и увеличение численности инженеров-разработчиков нужно делать на по-командной основе. Опыт управления проектом в такой конфигурации говорит о том, что “искрит” при передаче работы от одной команды в другую, поэтому лучше разделить работу команд на разные группы пользовательских сценариев и не давать командам пересекаться. Чтобы этого добиться, требуется достаточный запас (backlog) пользовательских историй.
Что такое хорошо
Наиболее важная часть пользовательской истории – условия приёмки. Это перечень условий, которые выдвигает заказчик, чтобы проверить качество продукта и понять, реализован ли функционал исполнителем-разработчиком «как надо».
Условия приёмки – концепция, которая отчасти противоречит той корпоративной логике, с которой многие из нас привыкли сталкиваться в крупных компаниях. Мы зачастую видим понятное, в общем-то, нежелание отдельных сотрудников брать на себя ответственность за определение качества передаваемого продукта заказчику – было бы лучше, если бы контроль качества проводился каким-то третьим лицом. Однако наиболее странная практика – поручать проверку качества исполнителю, который и выполнял реализацию продукта. В жизни это выглядит как просьба написать ПМИ (программу и методику испытаний) от заказчика в адрес исполнителя, после чего исполнитель сдает ПО по данному документу, по сути проконтролировав сам себя.
Вне зависимости от формата описания критериев готовности ПО – условия приемки или ПМИ, это тот раздел требований, в создании которого необходим активное и деятельное участие заказчика.
Договор и спринты
Карта пользовательских сценариев, описание этих пользовательских сценариев в виде набора пользовательских историй, создают модульные бизнес-требования, которые нужно использовать для сбора предложений от потенциальных исполнителей на рынке, а также для управления проектом в процессе разработки. Структура требований с возможностью их менять позволяет определять набор и очередность разрабатываемых блоков, устанавливать приоритеты отдельных элементов функциональности, которые заказчик планирует выводить на рынок.
Наши заказчики включают в качестве приложения к договору структуру работ, определенную в соответствии с пользовательскими сценариями, добавляют в приложение к договору оценку, которую даёт исполнитель по отдельным пользовательским историям (именно по историям), договариваются о механизме Change Request (CR), а также о механизмах допустимого превышения бюджета (если заказчик принимает для себя такую опцию) и организовывают разработку по спринтам в соответствии с блоками отдельных пользовательских историй. Исполнитель-разработчик может предоставлять заказчику график поставки отдельных пользовательских историй. Исходя из нашего опыта можно заключить, что этот график не обязательно должен быть жёстким.
